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Scope 



The present document provides the stage 3 specification of the Rq interface. The functional requirements and the 
stage 2 specifications of the Rq interface are contained in ES 282 001 [1] and ES 282 003 [2]. The Rq interface is the 
interface between the Service Policy Decision Function (SPDF) and the Access - Resource and Admission Control 
Function (A-RACF) and is used for QoS resource reservation information exchange between the SPDF and the 
A-RACF. Via the Rq interface the SPDF issues requests for resources in the access network, indicating IP QoS 
characteristics. The A-RACF uses the IP QoS information to perform admission control and indicate to the SPDF via 
the Rq interface its admission control decisions. Due to the possible business roles in an access environment, the SPDF 
may be either in the same domain or in a different domain as the A-RACF. 

The present document defines: 

• The information to be exchanged between SPDF and A-RACF over the Rq interface. 

• An Rq interface definition based on the Diameter protocol. 

In situations where no generic overload control mechanism is used on the Rq interface, the interface shall only be 
capable of supporting a one-to-one relationship between the A-RACF and SPDF (i.e. one SPDF may only contact one 
A-RACF, and that A-RACF may only contact that same SPDF). Overload control need not be supported in this 
situation due to the fact that it should be possible to traffic engineer the capabilities of the two entities, so that the 
capacity of one entity matches the capacity of the other. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were vaUd at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[I] ETSI ES 282 001 (V3.y.z): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); NGN Functional Architecture". 

[2] ETSI ES 282 003 (V3.y.z): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS): 
Functional Architecture". 
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[3] ETSI ES 282 004 (V3.y.z): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub- 
System (NASS)". 

[4] ETSI ES 283 034 (V2.y.z): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); Network Attachment Sub-System (NASS); e4 interface 
based on the DIAMETER protocol". 

[5] ETSI TS 183 017 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER 
protocol for session based policy set-up information exchange between the Application Function 
(AF) and the Service Policy Decision Function (SPDF); Protocol specification". 

[6] ETSI TS 129 207: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Policy control over Go interface (3GPP TS 29.207)". 

[7] ETSI TS 129 209: "Universal Mobile Telecommunications System (UMTS); PoHcy control over 

Gq interface (3GPP TS 29.209)". 

[8] ETSI TS 133 210: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); 3G security; Network Domain Security (NDS); IP network 
layer security (3GPP TS 33.210)". 

[9] IETF RFC 2960: "Stream Control Transmission Protocol". 

[10] IETF RCF 3309: "Stream Control Transmission Protocol (SCTP) Checksum Change". 

[11] IETF RFC 3588: "Diameter Base Protocol". 

[12] IETF RFC 4005: "Diameter Network Access Server Application". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 
Attribute-Value Pair (AVP): corresponds to an Information Element in a Diameter message 

NOTE: See RFC 3588 [11]. 
hard-state reservation: type of reservation whereby the requested resources are reserved without time limit 

NOTE: Hard-state reservations are terminated if the DIAMETER session is terminated. 

soft-state reservation: type of reservation whereby the requested resources are reserved for a finite amount of time, 
soft-state reservations are terminated when the DIAMETER session is terminated 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AAA AA-Answer 

AAR AA-Request 

AF Application Function 

A-RACF Access-Resource and Admission Control Function 

ASA Abort-Session-Answer 

ASP Application Service Provider 

ASR Abort-Session-Request 

ATM VC Asynchronous Transfer Mode Virtual Circuit 

AVP Attribute-Value Pair 

BGF Border Gateway Function 

RTF Basic Transport Functions 

lANA Internet Assigned Numbers Authority 

IP Internet Protocol 

IP -CAN IP-Connectivity Access Network 

NASREQ Network Access Server REQuirements 

RAA Re-Auth-Answer 

RACF Resource and Admission Control Function 

RACS Resource and Admission Control Subsystem 

RAR Re-Auth-Request 

RCEF Residual Code Excited Field 

RTCP Real-time Transport Control Protocol 

RTP Real-time Transport Protocol 

SDI Session Description Information 

SPDF Service-based Policy Decision Function 

STA Session-Termination-Answer 

STR Session-Termination-Request 

UDP User Datagram Protocol 

xDSL X Digital Subscriber Line 



Rq interface 



4.1 



Overview 



In the following clause, the Rq interface is described in detail concerning what type of information that needs to be 
transported between the SPDF and the A-RACF. The functional requirements and the stage 2 specifications of the Rq 
interface are contained in ES 282 001 [1] and ES 282 003 [2]. Due to the possible business roles in an access 
environment, an SPDF instance may be either in the same domain or in a different domain as the A-RACF instance with 
which it interacts. This means that Rq reference point should support both the case when an SPDF instance and the A- 
RACF instance with which it interacts are located in the same domain, and when they are located in different domains. 

The Rq reference point is an open vendor interface and an open operator interface. One A-RACF instance shall be able 
to serve more than one SPDF instance and one given SPDF instance may interact with a number of A-RACF instances, 
although on a session basis, it shall interact with only a single A-RACF instance. 
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4.2 Rq reference model 

The Rq interface is defined between the SPDF and the A-RACF. 
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BTF 
Transport Processing Functions 



Figure 1 : Rq interface architecture model 



4.3 Functional elements and capabilities 

4.3.1 Service Policy Decision Function (SPDF) 

The SPDF is a functional element that coordinates the resource reservations requests received from by the AF. The 
SPDF makes policy decisions using policy rules and forwards the session and media related information obtained from 
the AF to the A-RACF via the Rq reference point for admission control purposes. The functionality of the SPDF is 
further detailed in ES 282 003 [2]. 

4.3.2 Access- Resource Admission Control Function (A-RACF) 

The A-RACF is a functional element performing resource reservation admission control and network policy assembly. 
The A-RACF receives resource reservation requests from the SPDF via the Rq reference point. The functionality of the 
SPDF is further detailed in ES 282 003 [2]. 



5 Resource control procedures 

The resource control procedures are defined in seven interaction procedures: 

1) Reservation. 

2) Commit. 

3) Reservation and commit. 

4) Refresh. 

5) Modification. 

6) Release. 
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7) Event notification. 

These interactions are described in the following clauses. During the interactions Diameter AVPs are passed between 
the SPDF and the A-RACF. 

Figure 2 describes the flow states as maintained by the A-RACF F according to the procedures. Annex A provides a 
table further clarifying how states change at different events and actions taken by the A-RACF. 



Idle 



Fteceived STR 



Reservation 



V V 



Received STR or 
Release Request 



Reserved 



1 

Modification 
or Refresh 

I 



Commit 



ir V 



Committed 



1 

Modification 
or Refresh 

I 



Reservation&Commit 



Figure 2: Flow state 

The Flow-Status AVP (see clause 6.4.1 1) is used to define the action to be taken for each AA-Request made by the 
SPDF to the A-RACF. The rules for interpreting the Flow-Status AVP are the following: 

• Reservation: New Media-Description-Component AVP(s) and Media-Sub-Component AVP(s). Optional 
Flow-Status AVP(s) set to DISABLED (3). 

• Modification: Updated Media-Description-Component AVP(s) and/or Media-Sub-Component AVP(s). 
Flow-Status AVP not modified, unless the state needs to be modified (e.g. for committing a resource 
reservation, or for releasing a resource reservation). 

• Commit: Media-Description-Component AVP(s) and optionally Media-Sub -Component AVP(s) of existing 
reservations with Flow-Status AVP(s) set to ENABLED-UPLINK (0), ENABLED-DOWNLINK (1) or 
ENABLED (2). 

• ReservationAndCommit: New Media-Component-Description AVP(s) and Media-Sub-Component AVP(s). 
Flow-Status AVP(s) set to ENABLED-UPLINK (0), ENABLED-DOWNLINK (1) or ENABLED (2). 

• Release: Media-Description-Component AVP(s) and optionally Media-Sub-Component AVP(s) of existing 
reservations with Flow-Status AVP(s) set to REMOVED (4). 

• Refresh: Existing reservation unchanged (Media-Component-Description AVP(s) not specified or unchanged), 
Flow-Status AVP unchanged. 
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5.1 



Procedures at the SPDF 



5.1.1 



Initial Reservation for a Session 



The SPDF may request the A-RACF to allocate resources for a new session (i.e. make an initial reservation request). 
The SPDF issues such request by sending an AA-Request message to the A-RACF. This message contains one or more 
Media-Component-Description Attribute-Value-Pair(s) (AVP(s)). Each Media-Component-Description AVP describes 
the set of flows of a particular media type (i.e. it contains one or more Media-Sub-Component AVP(s) and requirements 
for the flows (see clause 6.4.16)). 

The SPDF may in the AA-Request include the Flow-Grouping AVP(s) to request a particular way for how the IP Flows 
are to be distributed to IP-CAN bearers. The SPDF may also forward an AF-Charging-Identifier AVP from the AF in 
the message for charging correlation purposes between AF and RACS. 

An AA-Request issued to request an initial reservation contains a new Session-Id obtained by the SPDF. As specified in 
RFC 3588 [11], the Session-Id is globally unique and is meant to uniquely identify a user session without reference to 
any other information. The Session-Id begins with the sender's identity encoded in the Diameterldentity type. 

The specific action that shall be performed by the A-RACF for each individual media and flow (i.e. the Reserve or the 
ReserveAndCommit operation) is defined by the Flow-Status AVP: 

• Reservation; the value of the Flow-Status AVP shall be set to DISABLED (3). 

• ReservationAndCommit; the value of the Flow-Status AVP shall be set to ENABLED-UPLINK (0), 
ENABLED-DOWNLINK (1) or ENABLED (2). 

• The Flow-Status AVP shall be specified in the Media-Component-Description AVP and in the 
Media-Sub-Component AVP(s). The Flow-Status AVP shall be set to the same value in both these AVPs. 

Table 1 : Initial Reservation operations 



Message 
Type 


Flow-Status AVP at the level of: 


Meaning 


Media 


Sub-Media 


AAR 


New Media, 
DISABLED 


New flow, 
DISABLED 


Reserve Resources for all the flows in the request. The 
media(s) and flow(s) descriptions MUST be new ones. 


AAR 


[New Media, 
ENABLE*] 


New flow, 
ENABLE* 


Reserve Resources. In addition, commit resources for some 
of the flows. The media(s) and flow(s) descriptions MUST be 
new ones. 



As specified in clause 8.9 of RFC 3588 [11], the SPDF may specify the Authorization-Lifetime AVP in the AA-Request 
to request a maximum lifetime for a session. To request a hard-state session the SPDF shall omit the 
Authorization-Lifetime AVP in the AA-Request. To request a soft-state session the SPDF shall specify this AVP in the 
AA-Request. 

The AA- Answer may contain the Authorization-Lifetime AVP. The AA- Answer may contain the Auth-Grace-Period 
AVP in addition to the Authorization-Lifetime AVP. The Authorization-Lifetime AVP specifies the maximum number 
of seconds before the Session must be refreshed by the SPDF. The Auth-Grace-Period AVP contains the number of 
seconds the A-RACF will wait for a Refresh following the expiration of the Authorization-Lifetime AVP. 

Whether the Authorization-Lifetime AVP and Auth-Grace-Period need to be included in the AA- Answer is a local 
decision of the A-RACF. This means that the SPDF may be offered a soft-state reservation although it asked for 
hard-state or a hard-state reservation although it asked for soft-state. Should the SPDF not accept what is offered by the 
A-RACF it must explicitly terminate the session. 

The SPDF may specify the Reservation-Priority AVP (see clause 6.4.23) as a main AVP of the AA-Request in order to 
assign a priority to the request. The SPDF may further specify the Reservation-Priority AVP in 

Media-Component-Description AVP(s) in order to assign priority to individual media. If the Reservation-Priority AVP 
is not specified the requested priority is DEFAULT. 

The SPDF may specify, in the Specific-Action AVP of the AA-Request through which the initial reservation request is 
made, the events of which it wants to be informed. The supported events are listed in clause 6.4.13. 



£75/ 



1 2 ETSI TS 1 83 026 V3.1 .1 (201 0-03) 

The SPDF may specify in the initial AAR the authorization context to be used for a media component or for the session 
by including one or more Media- Authorization-Context-Id AVP or Authorization-Package-Id AVPs respectively. In the 
case of a multicast reservation, the derived authorisation context stored in A-RACF may provide information on the 
multicast channels allowed or not allowed during the session and their respective QoS requirements. 

Should the AA- Answer contain one or more Session-Bundle-Id AVPs the SPDF shall store the association between the 
Session-Bundle-Id AVP(s) and the Session-ID AVP of the session in question. 

The behaviour when the SPDF does not receive an AA- Answer, or when it arrives after the internal timer waiting for it 
has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, is outside the scope of the 
present document. 

5.1.2 Session Modification 

The SPDF may modify an existing session by sending an AA-Request to the A-RACF with zero or more updated 
Media-Component-Description AVP(s) and/or Media-Sub-Component AVP(s). The Session-Id shall be an existing one 
and refer to the session that is to be modified. The Reservation-Priority may be specified as a main AVP and/or in 
Media-Component-Description AVP(s). If the Reservation-Priority AVP is not specified the requested priority is 
DEFAULT. The SPDF may perform the following operations: 



• 



• 



• 



• 



Add a new flow within a media component by providing a new Media-Sub-Component AVP within the 
corresponding Media-Component-Description AVP. 

Add a new flow within a new media component by providing a new Media-Component-Description AVP. 

Modify a media component by updating the corresponding Media-Component-Description AVP (e.g. increase 
or decrease the allocated bandwidth). 

Modify a flow within a media component by updating the corresponding Media-Sub-Component AVP. 

Modify a media flow state from Reserved to Committed by providing a Flow-Status AVP of the corresponding 
Media-Component-Description AVP and/or Media-Sub-Component AVP(s). The Flow-Status AVP shall be 
set to one of the values ENABLED-UPLINK, ENABLED-DOWNLINK or ENABLED, according to the 
direction in which the resources are to be committed. This operation requires that the media and flows are in 
the Reserved state prior to the AA-Request. 

Release a media component by providing the corresponding Media-Component-Description AVP with the 
Flow-Status AVP set to the value REMOVED. 

Release a flow within a media by providing the corresponding Media-Sub-Component AVP with the 
Flow-Status AVP set to the value REMOVED. 

Refresh a soft-state session by providing an AA-Request message containing the Session-Id of the session that 
is to be refreshed. The AA-Request may contain the Authorization-Lifetime AVP to request a maximum 
lifetime of the refreshed session. If this AVP is not included, the refresh message requests the lifetime to be 
extended by a default value. The AA-Request may contain Media-Component-Description AVP(s) and 
Media-Sub-Component AVP(s) (e.g. to modify media, flows and/or commit status). 

Modify the media level authorization context - provide new Media-Authorization-Context-Id AVP(s). The 
new Media- Authorization-Context-Id AVP(s) replace any authorization context previously associated to the 
media component. 

Modify the session level authorization context - provide new Authorization-Package-Id AVP(s). The new 
Authorization-Package-Id AVP(s) replace any authorization context previously associated to the session. 



The Flow-Status AVP in the Media-Sub-Component AVP shall always be the same as the Flow-Status AVP in the 
Media-Component-Description AVP containing the Media-Sub-Component AVP. When providing new 
Media-Component-Description AVP(s) and/or Media-Sub-Component AVP(s) the SPDF may in the AA-Request 
include the Flow-Grouping AVP(s) to request a particular way for how the IP Flows are to be distributed to IP-CAN 
bearers. 

The SPDF SHALL NOT use the RAA to modify the session service information. As an option, the SPDF MAY send an 
AAR command following an RAA to update the session service information. 
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Table 2: Modification operations 



Message Type 


Flow-Status AVP at the level of: 


Meaning 


Media 


Sub-Media 




AAR 


Existing Media 


Existing Flow, Unchanged 
Flow-Status 


Modify a media. In addition, modify a flow 
according to the new parameters specified in 
the Media-Sub-Component AVP. The Media 
and Flow must exist (see notes 1 , 2 and 5). 


AAR 


Existing Media 


New flow. Same Flow-Status 
AVP as in the media 
(see note 3) 


Modify a media. In addition, add a new flow 
in a media. The Flow must be new (see 
notes 3 and 5). 


AAR 


Existing Media 
(see note 4) 


REMOVED 


Modify a media. In addition, release an 
existing flow within an existing media. If the 
flow does not exist, the request shall be 
ignored by the A-RACF (see notes 2 and 5). 


AAR 


Existing Media, 
Modified Flow-Status 


Existing Flow, Flow-Status 
AVP = REMOVED 


Modify the commit status (see note 5). 


AAR 


Existing Media 


Existing Flow 


(see note 5). 


NOTE 1 : If the media is not an existing one, the AAR is interpreted as a reservation for a new media (see clause 5.1). 
NOTE 2: The parameters specified at flow-level (in the IVIedia-Sub-Component AVP(s)) take precedence over the 

parameters specified at media-level (in the updated Media-Component-Description AVP). 
NOTE 3: The Flow-Status AVP of a new flow within a media shall be the same as the Flow-Status of the media. For 

example, it makes no sense to commit a flow within a media that is not yet committed. 
NOTE 4: As the Modify operation is also used for the Commit operation, the Flow-Status AVP of the 

Media-Component-Description AVP may actually be modified. 
NOTE 5: In case of a soft-state reservation, extend its lifetime. 



The behaviour when the SPDF does not receive an AA- Answer, or when it arrives after the internal timer waiting for it 
has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, is outside the scope of the 
present document. 

5.1 .3 Session Termination 

The SPDF may issue a Session-Termination-Request (STR) command to the A-RACF, in order to terminate the session. 
This command releases all the resources associated with the session identified by the provided Session-Id AVP. 

Table 3: Termination operations 



Message 
Type 


Flow-Status AVP at the level of: 


Meaning 


Media 


Sub-Media 


STR 






Release a session: all the media(s) and flow(s) within 
that session are released 



When receiving an Abort-Session-Request (ASR) message from the A-RACF the SPDF shall if the session involves 
BGF resources release those resources and inform the AF of that the session identified by the Session-Id AVP is 
terminated. If the ASR message contains one or more Session-Bundle-Id AVPs the SPDF shall perform these 
procedures for all sessions associated with the Session-Bundle-Id AVP(s). 

5.1.4 Event notification 

Notifications for specific events may be implicitly requested through policies established in the A-RACF. The SPDF 
may further specify, in the Specific-Action AVP of an initial AA-Request command, the events of which it wants to be 
informed. The supported events are listed in clause 6.4. 

As an option, when the SPDF receives an RAR command from the A-RACF, this may result in the SPDF sending an 
AAR command to the A-RACF to update the service information. However, application-specific authentication and/or 
authorization messages are not mandated for the Rq application in response to an RAR command. 
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5.2 



Procedures at the A-RACF 



5.2.1 Initial Reservation for a Session 

An initial AA-Request contains one or more Media-Component-Description AVP(s) including one or more 
Media-Sub-Component AVP(s). For initial reservation requests in which the Session-Id is new the 
Media-Component-Number(s) and Flow-Number(s) are interpreted by the A-RACF as new ones. 

The Reservation-Priority AVP may be specified (see clause 6.4.23) main AVP in the AA-Request. The AA- Answer 
from the A-RACF may echo the Reservation-Priority AVP. If the Reservation-Priority AVP is not specified in the 
AA-Request, the priority associated with the reservation shall be DEFAULT. If the A-RACF is not able to comply with 
the requested priority level, the entire reservation shall fail and the A-RACF shall include the 
Experimental-Result-Code AVP with the value PRIORITY_NOT_GRANTED. 

When provided as a main AVP in an AA-Request, the Reservation-Priority AVP indicates the priority of the message to 
the A-RACF. The A-RACF may use this indication when receiving and processing the message (e.g. high priority 
AA-Request messages may be assigned precedence over low priority AA-Request messages). 

Upon reception of an AF- Application-Identifier AVP in an initial AA-Request from the SPDF, the A-RACF shall store 
this identifier together with the states created and maintained for the new session for the purpose of charging correlation 
between AF and RACS. The identifier is opaque to the A-RACF. 

The A-RACF shall identify the access profile that applies to the AA-Request from an identifier. This identifier comes in 
the form of the Subscriber ID, the Globally Unique IP Address, or both (see clause 5.2.2.2.7 in ES 282 003 [2]). The 
mapping of these parameters to the Diameter AVPs is described in table 4. If the A-RACF does not receive at least one 
of these parameters, it shall return an AA- Answer that include a Result-Code AVP set to the value 
DIAMETER_MISSING_AVP. The Failed-AVP AVP should be included in the message. The Failed-AVP AVP must 
contain an example of the missing AVP. The value field of the missing AVP example should be of correct minimum 
length and contain zeroes. 

If the A-RACF cannot identify an access profile that applies to the AA-Request, it shall return an 
Experimental-Result-Code AVP to the SPDF set to ACCESS_PROFILE_FAILURE. 

Table 4: Mapping of information element names to Diameter AVPs 



Information element name 


Mapping to Diameter AVP 


Cat. 


AVP used in 


Subscriber ID in RACS [2] and in NASS [3] 


User-Name 





Rq and e4 [4] 


Globally Unique IP Address in RACS [2] and 
in NASS [3] 


Globally-Unique-Address 





Rq and e4 [4] 


QoS Profile in NASS [3] 


QoS-Profile 





e4[4] 


Requestor Name in RACS [2] 


AF-Application-ldentifier 





Rq 


Requestor Name in NASS [3] 


Application-Class-ID 





e4[41 


Media Type in NASS [3] and in RACS [2] 


IVIedia-Type 





Rq and e4 [4] 


Reservation Class in RACS [2] 


Reservation-Class 





Rq 


Transport Service Class in RACS [2] and in 
NASS [3] 


Transport-Class 





Rq and e4 [4] 


Service Class in RACS [2] 


Service-Class 





Rq 


Authorization package ID in RACS [2] 


Authorization-Package-Id 





Rq and Gq' [5] 


IVIedia Authorization context ID 


Media-Authorization-Context-Id 





Rq and Gq' [5] 



If the identified access profile contains one or more QoS Profiles the A-RACF shall for each 

Media-Component-Description AVP in the AA-Request use the combined meaning of the AF- Application-Identifier 
AVP, the Transport-Class AVP and the Media-Type AVP to identify a QoS Profile to which the request applies. For 
this identification process the AF-Application-Identifier AVP, the Transport-Class AVP and the Media-Type AVP in 
the AA-Request received over Rq shall be matched with the information stored in the A-RACF that corresponds to the 
Application-Class-ID AVP, the Transport-Class AVP and the Media-Type AVP in the QoS Profile(s) obtained from 
NASS via e4 [3]. 

It should be noted that an access profile obtained from NASS via e4 ES 283 034 [4] may contain one or more QoS 
Profile AVPs with left out Application-Class-ID AVP, Transport-Class AVP and/or Media-Type AVP. The absence of 
these AVPs allows the A-RACF to apply default QoS Profiles to any Requestor Name, any Transport Service Class, 
and any Requestor Name and Transport Service Class. 
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If the access profile does not contain any QoS Profile the A-RACF shall instead apply a default QoS Profile to the 
request. If the Reservation-Priority AVP is not specified in the Media-Component-Description AVP for which a QoS 
profile applies the requested priority is DEFAULT. 

The A-RACF shall return an Experimental-Result-Code AVP to the SPDF set to QOS_PROFILE_FAILURE if the 
request needs to be denied for any of the following reasons: 

• The User-Name AVP and/or the Globally-Unique-Address AVP do not match any access profile. 

• The AF- Application-Identifier AVP, Transport-Class AVP and Media-Type AVP do not match any QoS 
profile of the access profile (identified by the User-Name AVP and/or the Globally-Unique-Address AVP). 

• The Max-Requested-Bandwidth-UL AVP and/or the Max-Requested-Bandwidth-DL AVP are larger than what 
is allowed by the QoS Profile matching the request (i.e. the Maximum-Allowed-Bandwidth-UL AVP and/or 
the Maximum-Allowed-Bandwidth-DL AVP obtained via e4). 

• The Reservation-Priority AVP in the Media-Component-Description AVP is larger than the maximum priority 
allowed by the QoS profile matching the request (i.e. the maximum priority allowed by a QoS profile is 
received in the Reservation-Priority AVP obtained via e4). 

NOTE: Only the first failure reason is possible for access profiles that do not contain a QoS Profile. 

Any value of the Flow-Status AVP received in an initial AA-Request (in which the Session-Id is new) different from 
ENABLED-UPLINK, ENABLED -DOWNLINK, ENABLED or DISABLED shall result in an error. If the Flow-Status 
AVP has the value REMOVED the A-RACF shall return an AA- Answer containing a Failed- AVP AVP and a 
Result-Code AVP with the value DIAMETER_INVALID_AVP_VALUE. 

In case the operation fails due to lack of resources, the A-RACF shall include the Experimental-Result-Code AVP set to 
the value INSUFFICIENT_RESOURCES. 

An initial reservation request can be admitted by the A-RACF if for all media streams in the session, the resource 
requirements fit within the constraints of remaining envelopes of unused resources. The A-RACF is presumed to exhibit 
"atomic" reservation semantics (i.e. either all reservations are admitted, or none of them). Once a reservation is 
admitted, the corresponding amount of resources is removed from the pool of available resources. 

If the request is admitted the A-RACF must send an AA- Answer back to the SPDF and include the Result-Code AVP 
set to the value DIAMETER_SUCCESS. 

Upon successful reservation, the A-RACF shall store the Diameter base protocol Session-Id received in the AA-Request 
through which the initial reservation request was made, and the Media-Component-Number(s) and Flow-Number(s). It 
shall also create an instance of the state machine illustrated in figure 2 for each media in the session and store the state 
of each media of the session. 

The AA-Request may contain Authorization-Package-Id AVP(s) or Media-Authorization-Context-Id AVP(s). The 
A-RACF shall use these parameters to identify the authorization context for the session or media component. The 
parameters may be used to derive the appropriate policies to be passed to an RCEF through the Re reference point. Any 
Authorization-Package-Id AVP or Media- Authorization-Context-Id AVPs that cannot be correlated to a locally defined 
authorization context shall result in an error. The A-RACF shall return an AA-Answer containing a Failed- AVP AVP 
and Experimental-Result-Code AVP with the value INVALID_SERVICE_INFORMATION. 

The AA-Request may contain the Authorization-Lifetime AVP. The A-RACF shall interpret the presence of the 
Authorization-Lifetime AVP as a request for a soft-state reservation and the absence of this AVP as a request for a 
hard-state reservation. The A-RACF may however return the Authorization-Lifetime AVP or the pair of 
Authorization-Lifetime AVP and Auth-Grace-Period AVP although the AA-Request did not contain the 
Authorization-Lifetime AVP. The A-RACF thereby offers a soft-state reservation although the request was for 
hard-state. The A-RACF may also choose not to return the Authorization-Lifetime AVP and the Auth-Grace-Period 
AVP although the AA-Request contained the Authorization-Lifetime AVP. The A-RACF thereby offers a hard-state 
reservation although the request was for soft-state reservation. 

The Authorization-Lifetime indicates when the A-RACF expects a Refresh from the SPDF. The Auth-Grace-Period 
AVP can only be specified in addition to the Authorization-Lifetime AVP. 

As specified in clause 8.9 of RFC 3588 [11] the server (i.e. the A-RACF) may return the Authorization-Lifetime AVP 
set to a value equal to, or smaller, than the value of the Authorization-Lifetime AVP provided by the SPDF. 
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The A-RACF may include one or more Session-Bundle-Id AVPs in the AA-Answer. The Session-Bundle-Id AVP 
identifies a group of sessions to which the session belongs. The value of this AVP and which sessions that belong to a 
certain such value are chosen by the A-RACF. The value if the Session-Bundle-Id AVP is meaningful only for the 
A-RACF. 

If the Specific-Action AVP is included in the initial AA-Request, notification for the given event(s) shall be activated 
by the A-RACF. The supported events are listed in clause 6. 

5.2.2 Session Modification 

An AA-Request issued to modify an existing session may contain zero or more Media-Component-Description AVP(s) 
including one or more Media-Sub-Component AVP(s). For modification requests in which the Session-Id is an existing 
one the Media-Component-Number(s) and Flow-Number(s) of existing reservations shall be existing ones. 
Media-Component-Number(s) and Flow-Number(s) of new Media-Component-Description AVP(s) and 
Media-Sub-Component AVP(s) are interpreted by the A-RACF as new ones. 

For an AA-Request issuing a session modification operation the Flow-Status AVP must be set to a value representing a 
state to which the session is allowed to enter from its current state. The allowed state transitions are illustrated in 
figure 2. Should the Flow-Status AVP be set to a disallowed value the A-RACF shall return an AA-Answer containing 
a Failed- AVP AVP and a Result-Code AVP with the value DIAMETER_INVALID_AVP_VALUE. 

If the A-RACF is unable to modify the status of a reservation to ENABLED-UPLINK, ENABLED-DOWNLINK or 
ENABLED, the A-RACF shall issue an error message to the SPDF with an Experimental-Result-Code AVP set to the 
value COMMIT_FAILURE. If the status of a reservation is one of the values ENABLED-UPLINK, 
ENABLED-DOWNLINK or ENABLED, the AA-Request should not contain a Flow-Status AVP set to DISABLED. If 
it does, the A-RACF shall return an AA-Answer to the SPDF with an Experimental-Result-Code AVP set to the value 
MODIFICATION_FAILURE. If the A-RACF is not able to re-initialize the lifetime of the reservation, it shall return an 
AA-Answer to the SPDF with an Experimental-Result-Code AVP set to the value REFRESH_FAILURE. 

If a flow-level operation fails, the entire Session Modification operation fails. In case the A-RACF determines that the 
request cannot be admitted due to insufficient resources, it shall return an Experimental-Result-Code AVP to the SPDF 
set to the value INSUFFICIENT_RESOURCES. The A-RACF shall return an Experimental-Result-Code AVP to the 
SPDF set to QOS_PROFILE_FAJLURE if the request needs to be denied for any of the reasons listed in clause 5.2. 1 
associated with this value. 

In case the Specific-Action AVP, the AF-Charging-Identifier AVP, the Flow-Grouping AVP, the Service-Class AVP, 
the User-Name AVP or the Globally-Unique-Address AVP was provided in an initial AA-Request with a value 
different from the value of the AVP(s) in a modifying AA-Request, the A-RACF shall return an AA-Answer containing 
a Failed- AVP AVP and a Result-Code AVP with the value DIAMETER_INVALID_AVP_VALUE. 

Upon successful session modification, the A-RACF must send an AA-Answer back to the SPDF with the Result-Code 
AVP set to DIAMETER_SUCCESS. 

Upon a successful refresh operation, the A-RACF shall in the AA-Answer return the Authorization-Lifetime AVP with 
a value equal or smaller than the Authorization-Lifetime AVP of the AA-Request (if any). The Auth-Grace-Period AVP 
can only be specified in addition to the Authorization-Lifetime AVP. 

Whether Authorization-Lifetime AVP and Auth-Grace-Period AVP need to be specified in the AA-Answer is a local 
decision for the A-RACF. 

If a reference to a previously negotiated Media-Component-Description AVP and/or Media-Sub-Component AVP for 
the session in question is omitted in the AA-Request, the corresponding flow is not impacted by the Modification 
operation. 

5.2.3 Session Termination 

If all IP flows within a SPDF session need to be terminated, the A-RACF shall inform the SPDF about this event by 
sending an Abort-Session-Request (ASR) message with the appropriate Abort-Cause AVP value. The A-RACF may 
include one or more Session-Bundle-Id AVPs in order to inform the SPDF of that several sessions identified by the 
provided Session-Bundle-Id AVP(s) are terminated. 
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Upon receipt of a Session-Termination-Request (STR) message from the SPDF the A-RACF shall release all the 
resources associated with the session identified through the provided Session-Id AVP. If an unknown Session-Id is 
provided in the STR the A-RACF shall return a STA message to the SPDF with the Result-Code AVP set to 
DIAMETER_UNKNOWN_SESSION_ID. 

5.2.4 Event Notification 

If an event for which notification is requested occurs, the A-RACF shall send an unsolicited RAR message to the SPDF 
containing: 

• The value of the Specific- Action AVP, indicating the event that occurred. 

• Optionally, the appropriate Abort-Cause AVP value. 



6 Rq protocol 

The Rq protocol is based on Diameter (RFC 3588 [11]). 

6.1 Protocol support 

The Diameter Base Protocol as specified in RFC 3588 [11] used to support information transfer on the Rq interface. 
RFC 3588 [11] shall apply except as modified by the defined Rq application specific procedures, Attribute-Value-Pairs 
(AVPs) as well as Experimental-Result-Code AVP and Specific-Action AVP values defined in the present document. 
Unless otherwise specified, the procedures of RFC 3588 [11] (including error handling and unrecognized information 
handling) are unmodified. In addition to the AVPs defined in clause 6.4, the Diameter AVPs from the Diameter base 
application (RFC 3588 [11]) are reused within the Diameter messages sent over the Rq reference point. 

The support of AVPs from the Diameter Network Access Server Application (NASREQ) (RFC 4005 [12]) is not 
required from Diameter implementations that conform to the present document. Accounting functionality (Accounting 
Session State Machine, related command codes and AVPs) is not used in the Rq specification re-uses the Diameter 
application defined for the 3GPP Gq interface (TS 129 209 [7]). The Gq Diameter application is defined as an IETF 
vendor specific Diameter application with Application-ID 16777222. The vendor identifier assigned by lANA to 3GPP 
is 10415 and the vendor identifier assigned by lANA to ETSI is 13019. The Vendor-Id header for AVPs imported from 
TS 129 209 [7] shall be set to 3GPP (19415), while AVPs defined in the present document or imported from 
TS 183 017 [5] or ES 283 034 [4] shall be set to ETSI (13019). 

With regard to the Diameter protocol defined over the Rq reference point, the A-RACF acts as a Diameter server, in the 
sense that it is the network element that handles authorization requests for a particular realm. The SPDF acts as the 
Diameter Client, in the sense that is the network element requesting authorization to use bearer path network resources. 

The support of Diameter agents between the A-RACF and the SPDF, is optional where the Rq is intra operator 
i.e. A-RACF and SPDF are all in the same domain. 



6.1 .1 Advertising Application Support 

The Capabilities-Exchange-Request (CER) and Capabilities-Exchange- Answer (CEA) commands are specified in the 
Diameter Base Protocol RFC 3588 [11]. 

Due to the definition of the commands used over the Rq reference point, the Vendor-Specific-Application-Id AVP 
cannot be used instead of the Auth- Application-Id AVP. Therefore the Gq application identifier shall be included in the 
Auth- Application-Id AVP. 

Additionally, the SPDF and the A-RACF shall advertise the support of additional Vendor-ID AVPs by including the 
ETSI value (13019) and 3GPP (10415) in two different Supported- Vendor-Id AVPs of the CER and CEA commands. 

6.1 .2 Transport protocol 

Diameter messages over the Rq reference point shall make use of SCTP RFC 2960 [9] and shall utilize the new SCTP 
checksum method specified in RFC 3309 [10]. 
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6.1 .3 Securing Rq messages 

For secure transport of Diameter messages, see TS 133 210 [8]. 

6.1.4 Use of sessions 

The Session-Termination-Request (STR) and Session-Termination- Answer (STA) commands defined in RFC 3588 [11] 
shall be used in order to terminate the sessions which are established via the AAR and AAA commands. 

If an RAR command is specifically corresponding to an established Rq session, the RAR shall contain the session-id of 
the established session. 

Otherwise (e.g. in case of a failure multicast notification which has no corresponding Rq established session), a session- 
id different from the session-ids of all the established Rq sessions shall be allocated by the x-RACF for the RAR 
command. Both the SPDF and the x-RACF shall not maintain a new session status with the session-id after the 
RAR/RAA interaction. No AAR/ AAA and STR/STA commands are required to be used for this kind of sessions. 



6.2 Rq messages 



Existing Diameter command codes from the Diameter base protocol RFC 3588 [11] and the NASREQ Diameter 
application RFC 4005 [12] are used at the Rq interface. The Application-ID of 16777222 is used together with the 
command code to identify the Rq messages. 

New AVPs are represented in bold. 

6.2.1 AA-Request (AAR) Command 

The AA-Request command (AAR), indicated by the Command-Code field set to 265 and the "R" bit set in the 
Command Flags field, is sent by the SPDF to the A-RACF for reserve, commit, modify, release and refresh operations. 

Message Format: 



<AA-Request> : 



< Diameter Header: 2S5, REQ, PXY > 

< Session-Id > 

{ Auth-Application-ID } 

{ Origin-Host } 

{ Origin-Realm } 

{ Destination-Realm } 

[Destination-Host ] 

Specific-Action ] 

AF-Charging-Identif ier ] 

Media-Component-Description ] 

Flow-Grouping ] 

Reservation-Priority ] 

User-Name ] 

Globally-Unique-Address ] 

Service-Class ] 

Overbooking indicator] 

Authorization-Package-Id ] 

Authorization-Lifetime ] 

Proxy- Info ] 

Route-Record ] 

AVP ] 



6.2.2 AA-Answer (AAA) Command 

The AA-Answer command (AAA), indicated by the Command-Code field set to 265 and the "R" bit cleared in the 
Command Flags field, is sent by the RACF to the SDPF in response to the AAR command. The A-RACF may confirm 
the priority associated with the reservation by echoing the Reservation-Priority AVP (see clause 6.4.23). 

Message Format: 



<AA-Answer> 



Diameter Header: 265, 
Session-Id > 
Auth-Application-ID } 
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{ Origin-Host } 

{ Origin-Realm } 

[ Result -Code ] 

[ Experimental-Result ] 

[ Error-Message ] 

[ Error-Reporting-Host ] 

[ Auth-Grace-Period ] 

*[ Session-Bundle-Id ] 

[ Reservation-Priority ] 

[ Authorization-Lifetime ] 

* [ Failed-AVP ] 

* [ Proxy- Info ] 

* [ AVP ] 



6.2.3 Re-Auth-Request (RAR) Command 



The RAR command, indicated by the Command-Code field set to 258 and the "R" bit set in the Command Flags field, is 
sent by the A-RACF to the SPDF in order to indicate a specific action. 

The values INDICATION_OF_RELEASE_OF_BEARER, INDICATION_OF_SUBSCRIBER_DETACHMENT and 
INDICATION_OF_RESERVATION_EXPIRATION of the Specific-Action AVP shall not be combined with each 
other in a Re-Auth-Request. 



Message Format: 



<RA-Request> : 



Diameter Header: 258, REQ, PXY > 
Session-Id > 
Origin-Host } 
Origin-Realm } 
Destination-Realm } 
Destination-Host } 
Auth-Application-Id } 
Specific-Action } 
Flow-Description ] 
Globally-Unique-Address ] 
Logical -Access-Id ] 
Flows ] 
Abort -Cause ] 
Origin-State-Id ] 
Proxy- Info ] 
Route-Record ] 
AVP ] 



6.2.4 Re-Auth-Answer (RAA) Command 

The RAA command, indicated by the Command-Code field set to 258 and the "R" bit cleared in the Command Flags 
field, is sent by the SPDF to the A-RACF in response to the RAR command. 

Message Format: 



<RA-Answer> 



25£ 



PXY 



< Diameter Header: 

< Session-Id > 

{ Origin-Host } 
{ Origin-Realm } 

Result-Code ] 

Experimental-Result ] 

Media -Component -Description 

Flow-Grouping ] 

Origin-State-Id ] 

Error-Message ] 

Error-Reporting-Host ] 

Failed-AVP ] 

Proxy- Info ] 

AVP ] 
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6.2.5 Session-Termination-Request (STR) Command 

The STR command, indicated by the Command-Code field set to 275 and the "R" bit set in the Command Flags field, is 
sent by the SPDF to inform the A-RACF that an authorized session shall be terminated. 

Message Format: 

<ST-Request> ::= < Diameter Header: 275, REQ, PXY > 

< Session-Id > 

{ Origin-Host } 

{ Origin-Realm } 

{ Destination-Realm } 

{ Auth-Application-ID } 

{ Termination-Cause } 

[ Destination-Host ] 
* [ Class ] 

[ Origin-State-Id ] 
* [ Proxy- Info ] 
* [ Route-Record ] 
* [ AVP ] 

6.2.6 Session-Termination-Answer (STA) Command 

The STA command, indicated by the Command-Code field set to 275 and the "R" bit cleared in the Command Flags 
field, is sent by the A-RACF to the SPDF in response to the STR command. 

Message Format: 

<ST-Answer> ::= < Diameter Header: 275, PXY > 

< Session-Id > 

{ Origin-Host } 

{ Origin-Realm } 

[ Result -Code ] 

[ Experimental-Result ] 

[ Error-Message ] 

[ Error-Reporting-Host ] 
* [ Failed-AVP ] 

[ Origin-State-Id ] 
* [ Redirect-Host ] 

[ Redirect -Host -Usage ] 

[ Redirect-Max-Cache-Time ] 
* [ Proxy- Info ] 

[ AVP ] 

6.2.7 Abort-Session-Request (ASR) Command 

The ASR command, indicated by the Command-Code field set to 274 and the "R" bit set in the Command Flags field, is 
sent by the A-RACF to inform the SPDF that all resources for the authorized session have become unavailable. 

Message Format: 

<AS-Request> ::= < Diameter Header: 274, REQ, PXY > 

< Session-Id > 

{ Origin-Host } 

{ Origin-Realm } 

{ Destination-Realm } 

{ Destination-Host } 

{ Auth-Application-ID } 

{ Abort -Cause } 
*[ Session-Bundle-Id ] 

[ Origin-State-Id ] 
* [ Proxy- Info ] 
* [ Route-Record ] 

[ AVP ] 
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6.2.8 Abort-Session-Answer (ASA) Command 

The ASA command, indicated by the Command-Code field set to 274 and the "R" bit cleared in the Command Flags 
field, is sent by the SPDF to the A-RACF in response to the ASR command. 

Message Format: 

<AS-Answer> ::= < Diameter Header: 274, PXY > 

< Session-Id > 

{ Origin-Host } 

{ Origin-Realm } 

[ Result -Code ] 

[ Experimental-Result ] 

[ Origin-State-Id ] 

[ Error-Message ] 

[ Error-Reporting-Host ] 
* [ Failed-AVP ] 
* [ Redirected-Host ] 

[ Redirected-Host-Usage ] 

[ Redirected-Max-Cache-Time ] 
* [ Proxy- Info ] 
* [ AVP ] 

6.3 Experimental-Result-Code AVP values 

6.3.1 Experimental-Result-Code AVP values imported from TS 1 29 209 

The present document reuses existing Experimental-Result-Code AVP values defined in TS 129 209 [7]. This clause 
defines the specific values of the Experimental-Result-Code AVP: 

INVALID_SERVICE_INFORMATION(5061). 

The service information provided by the AF is invalid or insufficient for the server to perform the requested 
action. 

FILTER_RESTRICTIONS (5062). 

The Flow-Description AVP(s) cannot be handled by the server because restrictions defined in clause 6.4.7 are 
not observed. 

6.3.2 Experimental-Result-Code AVP values defined in the present 
document 

This clause defines the specific values of the Experimental-Result-Code AVP (vendor-id is ETSI): 

INSUFFICIENT_RESOURCES (4041). 

The A-RACF indicates insufficient resources to perform the requested action. 

M0DIFICAT10N_FAILURE (5041). 

The A-RACF or BGF indicates that the resources reservation could not be modified. This is a permanent 
failure. 

C0MM1T_FAILURE (4043). 

The A-RACF indicates that the resources reservation could not be committed. 
REFRESH_FAILURE (4044). 

The A-RACF indicates that the lifetime of a reservation could not be extended. 
QOS_PROFILE_FAILURE (4045). 

The A-RACF indicates that the request did not match the QoS profile. 
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ACCESS_PROFILE_FAILURE (4046). 

The A-RACF indicates that the request did not match any access profile. 
PRIORITY_NOT_GRANTED (4047). 

The A-RACF indicates that the priority level of the request is not accepted. 

6.4 AVPs 

This clause summarizes the AVPs used in the present document, beyond those defined in the Diameter Base Protocol. 

6.4.1 AVPs defined in tine present document 

Table 5 describes the Diameter AVPs defined in the present document, their AVP Code values, types, possible flag 
values and whether the AVP may be encrypted. The vendor-Id header of all AVPs defined in the present document shall 

be set to ETSI (13019). 

Table 5: Diameter AVPs defined in the present document 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Should 
not 


Must 
not 


May Encr. 


Session-Bundle-ld 


400 


6.4.24 


Unsigned32 


M, V 


P 






Y 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header 
bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For 
further details, see RFC 3588 [11]. 

NOTE 2: The value types are defined in RFC 3588 [11]. 



6.4.2 AVPs imported from TS 1 29 209 

The present document reuses existing AVP(s) used already at the Gq interface TS 129 209 [7]. Not all the AVPs 
defined in TS 129 209 [7] are reused (e.g. Access-Network-Charging-Identifier-Value AVP). 

Table 6 describes the Diameter AVPs defined for the Gq interface protocol [7] and used in the present document, their 
AVP Code values, types, possible flag values and whether the AVP may be encrypted. Flags values are described in the 
context of the present document rather than in the context of the application where they are defined. AVPs defined in 
TS 129 209 [7] but not listed in the following table should not be sent by Diameter implementations conforming to the 
present document and shall be ignored by receiving entities. The Vendor-Id header for these AVPs shall be set to 3GPP 
(10415). 



£75/ 



23 



ETSI TS 183 026 V3.1.1 (2010-03) 



Table 6: Diameter AVPs imported from TS 129 209 [7] 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Should 
not 


Must 
not 


May Encr. 


Abort-Cause 


500 


6.4.5 


Enumerated 


M, V 


P 






Y 


AF-Application-ldentifier 


504 


6.4.6 


OctetString 


M, V 


P 






Y 


AF-Charging-ldentifier 


505 


6.4.25 


OctetString 


M, V 


P 






Y 


Flow-Description 


507 


6.4.7 


IPFilterRule 


M, V 


P 






Y 


Flow-Grouping 


508 


6.4.8 


Grouped 


M.V 


P 






Y 


Flow-Number 


509 


6.4.9 


Unsigned32 


M, V 


P 






Y 


Flows 


510 


6.4.10 


Grouped 


M, V 


P 






Y 


Flow-Status 


511 


6.4.11 


Enumerated 


M, V 


P 






Y 


Flow-Usage 


512 


6.4.12 


Enumerated 


M, V 


P 






Y 


Specific-Action 


513 


6.4.13 


Enumerated 


M, V 


P 






Y 


IVIax-Requested-Bandwidth-DL 


515 


6.4.14 


Unsigned32 


M, V 


P 






Y 


Max-Requested-Bandwidth-UL 


516 


6.4.15 


Unsigned32 


M, V 


P 






Y 


Media-Component-Description 


517 


6.4.16 


Grouped 


M, V 


P 






Y 


Media-Component-Number 


518 


6.4.17 


Unsigned32 


M, V 


P 






Y 


Media-Sub-Component AVP 


519 


6.4.18 


Grouped 


M, V 


P 






Y 


Media-Type 


520 


6.4.19 


Enumerated 


M, V 


P 






Y 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header 
bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For 
further details, see RFC 3588 [11]. 

NOTE 2: The value types are defined in RFC 3588 [11]. 



6.4.3 AVPs imported from TS 1 83 01 7 

Table 7 describes the Diameter AVPs defined for the Gq' interface protocol [5] and used in the present document, their 
AVP Code values, types, possible flag values and whether the AVP may be encrypted. Flags values are described in the 
context of the present document rather than in the context of the application where they are defined. AVPs defined in 
[5] but not listed in table 7 should not be sent by Diameter implementations conforming to the present document and 
shall be ignored by receiving entities. The Vendor-Id header for these AVPs shall be set to ETSI (13019). 

Table 7: Diameter AVPs imported from [5] 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Should 
not 


Must 
not 


May Encr. 


Reservation-Class 


456 


6.4.20 


Unsigned32 


M, V 


P 






Y 


Reservation-Priority 


458 


6.4.23 


Enumerated 












Service-Class 


459 


6.4.26 


UTFSString 


V 






M 


Y 


Overbooking-indicator 


460 


6.4.28 


Enumerated 


V 






M 


Y 


Authorization-Package-Id 


461 


6.4.29 


UTFSString 


V 






M 


Y 


Media-Authorization-Context-Id 


462 


6.4.30 


UTFSString 


V 






M 


Y 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header 

bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For further 
details, see RFC 3588 [11]. 

NOTE 2: The value types are defined in RFC 3588 [11]. 



6.4.4 AVPs imported from ES 283 034 

Table 8 describes the Diameter AVPs defined for the e4 interface protocol [4] and used in the present document, their 
AVP Code values, types, possible flag values and whether the AVP may be encrypted. Flags values are described in the 
context of the present document rather than in the context of the application where they are defined. AVPs defined 
in [4] but not listed in table 8 should not be sent by Diameter implementations conforming to the present document and 
shall be ignored by receiving entities. The Vendor-Id header for these AVPs shall be set to ETSI (13019). 
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Table 8: Diameter AVPs imported from [4] 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Should 
not 


Must 
not 


May Encr. 


Globally-Unique-Address 


300 


6.4.21 


Grouped 


M, V 








Y 


Address-Realm 


301 


6.4.22 


OctetString 


M, V 








Y 


Logical-Access-Id 


302 


6.4.31 


OctetString 


V 


M 






Y 


Transport-Class 


311 


6.4.27 


Unsigned32 


V 


M 






Y 


NOTE 1 : The AVP header bit denoted as "IVI", indicates whether support of the AVP is required. The AVP header 
bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For 
further details, see RFC 3588 [11]. 

NOTE 2: The value types are defined in RFC 3588 [11]. 



6.4.5 Abort-Cause AVP 

The Abort-Cause AVP (AVP code 500) is of type Enumerated, and it determines the cause of an ASR. The following 
values defined in [7] are used: 

BEARER_RELEASED (0) 

This value is used when the bearer has been deactivated as a result from normal signalling handling. For xDSL, 
the bearer may refer to an ATM VC. 

INSUFFICIENT_SERVER_RESOURCES ( 1 ) 

This value is used to indicate that the A-RACF is overloaded and needs to abort the session. 

INSUFFICIENT_BEARER_RESOURCES(2) 

This value is used when the bearer has been deactivated due to insufficient bearer resources at a transport 
gateway (e.g. RCEF for xDSL). 



6.4.6 AF-Application-ldentifier AVP 



The AF- Application-Identifier AVP (AVP code 504) is of type OctetString, and it contains information that identifies 
the particular service that the AF service session belongs to. This information may be used to differentiate QoS for 
different application services. 

For example the AF- Application-Identifier may be used as additional information together with the Media-Type AVP 
when the QoS class is selected. 

6.4.7 Flow-Description AVP 

• The Flow-Description AVP (AVP code 507) is of type IPFilterRule, and defines a packet filter for an IP flow 
with the following information: Direction (in or out). 

• Source and destination IP address (possibly masked). 

• Protocol. 

• Source and destination port (list or ranges). 

The IPFilterRule type shall be used with the following restrictions: 

• Only the Action "permit" shall be used. 

• No "options" shall be used. 

• The invert modifier " !" for addresses shall not be used. 

• The keyword "assigned" shall not be used. 
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If any of these restrictions is not observed by the AF, the server shall send an error response to the AF containing the 
Experimental-Result-Code AVP with value FILTER_RESTRICTIONS. 

The Flow description AVP shall be used to describe a single IP flow. 

The direction "in" refers to uplink IP flows, and the direction "out" refers to downlink IP flows. 

6.4.8 Flow-Grouping AVP 

The Flow-Grouping AVP (AVP code 508) is of type Grouped, and it indicates that no other IP Flows shall be 
transported together with the listed IP Flows in the same IP -CAN bearer. 

If Flow-Grouping AVP(s) have been provided in earlier service information, but are not provided in subsequent service 
information, the old flow grouping remains valid. 

If Flow-Grouping AVP(s) have been provided in earlier service information, and new Flow-Grouping AVP(s) are 
provided, the new flow grouping information replaces the previous information. Previous flow grouping information is 
invalidated even if the new Flow-Grouping AVP(s) affect other IP flows. 

A Flow-Grouping AVP containing no Flows AVP may be used to invalidate flow grouping information provided in 
earlier service information. A Flow-Grouping AVP containing no Flows AVP shall not be supplied together with other 
Flow-Grouping AVP(s). 

If earlier service information has already been provided, flow grouping information in subsequent service information 
shall not restrict the flow grouping further for IP flows already described in the previous service information. However, 
new IP flows described for the first time in the subsequent service information may be added to existing flow groups or 
in new flow groups. 

AVP Format: 

Flow-Grouping ::= < AVP Header: 508 > 
* [Flows] 

6.4.9 Flow-Number AVP 

The Flow-Number AVP (AVP code 509) is of type Unsigned32, and it contains the ordinal number of the IP flow(s), 
assigned according to the rules in annex C of TS 129 207 [6]. 

6.4.10 Flows AVP 

The Flows AVP (AVP code 510) is of type Grouped, and it indicates IP flows via their flow identifiers. If no 
Flow-Number AVP(s) are supplied, the Flows AVP refers to all Flows matching the media component number. 

AVP Format: 

Flows: := < AVP Header: x > 

{ Media-Component-Number} 
* [ Flow-Number] 

6.4.11 Flow-Status AVP 

The Flow-Status AVP (AVP code 5 11) is of type Enumerated, and describes whether the IP flow(s) are enabled or 
disabled. The Flow-Status AVP may be present in the Media-Description-Component AVP and/or in the 
Media-Sub-Component AVP. The following values are defined: 

ENABLED-UPLINK (0) 

This value shall be used to commit the corresponding resource reservation in the uplink direction. 
ENABLED-DOWNLINK (1) 

This value shall be used to commit the corresponding resource reservation in the downlink direction. 
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ENABLED (2) 

This value shall be used to commit a resource reservation in both directions. 

DISABLED (3) 

This value shall be used to indicate that the corresponding resource reservation is reserved only and not (yet) 
committed. 

REMOVED (4) 

This value shall be used to release all resources associated with the corresponding resource reservation. 

6.4.12 Flow-Usage AVP 

The Flow-Usage AVP (AVP code 5 12) is of type Enumerated, and it provides information about the usage of IP Flows. 
The following values are defined: 

NO_INFORMATION (0) 

This value is used to indicate that no information about the usage of the IP flow is being provided 
RTCP (1) 

This value is used to indicate that an IP flow is used to transport RTCP. 

NO_INFORMATION is the default value. 

NOTE: An SPDF may choose not to identify RTCP flows, e.g. in order to avoid that RTCP flows are always 
enabled by the A-RACF. 

6.4.13 Specific-Action AVP 

The Specific- Action AVP (AVP code 513) is of type Enumerated. Within an initial AA-Request the SPDF may use the 
Specific-Action AVP to request from the A-RACF notification of specific actions. If the Specific-Action AVP is 
omitted within the initial AA-Request, no notification of any of the events defined below is requested. 

The following event from TS 129 209 [7] is supported: 

INDICATION_OF_RELEASE_OF_BEARER(4) 

Within a RAR, this value shall be used when the A-RACF reports to the SPDF the release of a bearer (e.g. RCEF 
policies being removed). In the AAR, this value indicates that the SPDF requests the A-RACF to provide a 
notification at the removal of a bearer. In case of failure of a multicast request, the RAR message may include the 
address of the UE that requested the multicast flow and the flow description of the flow. 

In addition, the present document defines two new events: 

INDICATI0N_0F_SUBSCRIBER_DETACHMENT(6) 

Within a RAR, this value shall be used when the A-RACF reports to the SPDF that a subscriber has been detached. 
In the AAR, this value indicates that the SPDF requests the A-RACF to provide a notification at the detachment of a 

subscriber. 

INDICATI0N_0F_RESERVATI0N_EXPIRATI0N(7) 

Within a RAR, this value shall be used when the A-RACF reports to the SPDF that a reservation is about to expire. 
In the AAR, this value indicates that the SPDF requests the A-RACF to provide a notification when a reservation 
expires. 

Other events but the above-listed ones defined by TS 129 209 [7] are not relevant at the Rq interface and are not 
supported. If specified by the SPDF, these values are ignored by the A-RACF. 
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6.4.14 Max-Requested-Bandwidth-DL AVP 

The Max-Requested-Bandwidth-DL AVP (AVP code 515) is type Unsigned32, and it indicates the maximum requested 
bandwidth in bits per second for a downHnk IP flow. The bandwidth contains all the overhead coming from the IP -layer 
and the layers above, e.g. IP, UDP, RTP and RTP payload. 

6.4.15 Max-Requested-Bandwidth-UL AVP 

The Max -Bandwidth-UL AVP (AVP code 516) is of type Unsigned32, and it indicates the maximum requested 
bandwidth in bits per second for an uplink IP flow. The bandwidth contains all the overhead coming from the IP-layer 
and the layers above, e.g. IP, UDP, RTP and RTP payload. 



6.4.16 Media-Component-Description AVP 



The Media-Component-Description AVP (AVP code 517) is of type Grouped, and it contains service information for a 
single media component within a session. It may be based on the SDI exchanged between the AF and the AF client in 
the UE. The information shall be used by the A-RACF to determine the QoS requirements. 

Within one Diameter message, a single IP flow shall not be described by more than one Media-Component-Description 
AVP. 

The Media-Component-Description AVP may contain the Flow-Status AVP, which indicates the particular reservation 
operation to be performed on the media, as described in clauses 5.1 and 5.2. 

Bandwidth information provided within the Media-Component-Description AVP applies to all those IP flows within the 
media component, for which no corresponding information is being provided within Media-Sub-Component AVP(s). 

If a Media-Component-Description AVP is not supplied, or if optional AVP(s) within a Media-Component-Description 
AVP are omitted, but corresponding information has been provided in previous Diameter messages, the previous 
information for the corresponding IP flow(s) remains valid. 

AVP format: 

Media-Component-Description ::= < AVP Header: 517> 

{ Media-Component-Number } ; Ordinal number of the media comp. 
Media-Sub-Component ] ; Set of flows for one flow identifier 
AF-Application-Identif ier ] 
Media-Type ] 

Max-Requested-Bandwidth-UL ] 
Max-Requested-Bandwidth-DL ] 
Flow-Status ] 
RS-Bandwidth ] 
RR-Bandwidth ] 
Reservation-Priority ] 
Reservation-Class ] 
Transport-Class ] 
Media-Authorization-Context-Id ] 



6.4.17 Media-Component-Number AVP 



The Media-Component-Number AVP (AVP code 518) is of type Unsigned32, and it contains the ordinal number of the 
media component, assigned according to the rules in annex C of TS 129 207 [6]. 



6.4.18 Media-Sub-Component AVP 



The Media-Sub-Component AVP (AVP code 519) is of type Grouped, and it contains the requested QoS and filters for 
the set of IP flows identified by their common Flow-Identifier. The Flow-Identifier is defined in TS 129 207 [6]. 

The Media-Sub-Component AVP may contain the Flow-Status AVP, which indicates the particular reservation 
operation to be performed on the flow, as described in clauses 5.1 and 5.2. 
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Possible Bandwidth information provided within the Media-Sub-Component AVP takes precedence over information 
within the encapsulating Media Component Description AVP. If a Media-Sub-Component AVP is not supplied, or if 
optional AVP(s) within a Media-Sub-Component AVP are omitted, but corresponding information has been provided in 
previous Diameter messages, the previous information for the corresponding IP flow(s) remains valid, unless new 
information is provided within the encapsulating Media-Component-Description AVP. If Flow-Description AVP(s) are 
supplied, they replace all previous Flow-Description AVP(s), even if a new Flow-Description AVP has the opposite 
direction as the previous Flow-Description AVP. 

AVP Format: 

Media-Sub-Component ::= < AVP Header: 519 > 

{ Flow-Number } ; Ordinal number of the IP flow 
[ Flow-Status ] 
0*2 [ Flow-Description ] ; UL and/or DL 
[ Flow-Usage ] 

[ Max-Requested-Bandwidth-UL ] 
[ Max-Requested-Bandwidth-DL ] 

6.4.19 Media-Type AVP 

The Media-Type AVP (AVP code 520) is of type Enumerated, and it determines the media type of a session 
component. The following values are defined: 

AUDIO (0). 

VIDEO (1). 

DATA (2). 

APPLICATION (3). 

CONTROL (4). 

TEXT (5). 

MESSAGE (6). 

OTHER (OxFFFFFFFF). 

6.4.20 Reservation-Class AVP 

The Reservation-Class AVP (AVP code 456) is of type Unsigned32, and it contains an integer used as an index pointing 
to the traffic characteristics of the flow (e.g. burstiness and packet size). 

6.4.21 Globally-Unique-Address AVP 

The Globally-Unique-Address AVP (AVP code 300) is of type Grouped. 
AVP Format: 

Globally-Unique-Address ::= < AVP Header: 300 13019 > 

[Framed- IP- Address] 
[Framed- IPv6 -Prefix] 
[Address -Realm] 

6.4.22 Address-Realm AVP 

The Address-Realm AVP (AVP code 301) is of type OctetString. 
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6.4.23 Reservation-Priority AVP 



The Reservation-Priority AVP (AVP code 458) is of type Enumerated. It may be specified in an AA-Request as a main 
AVP in order to associate a priority with a resource reservation or modification request. It may also be specified as part 
of a Media-Component AVP in order to associate a priority with resource reservations requested for the media flows 
identified by the Media-Sub-Component AVP(s) in a Media-Component AVP. The following values of this AVP are 
specified: 

• DEFAULT (0): This is the lowest level of priority. If no Reservation-Priority AVP is specified as a main AVP 
in the AA-Request, this is the priority associated with a resource reservation or modification request. If no 
Reservation-Priority AVP is specified in a Media-Component-Description AVP, this is the priority associated 
with resource reservations requested for the media flows identified by the Media-Sub-Component AVP(s) in a 
Media-Component-Description AVP. 

PRIORITY-ONE (1). 

PRIORITY-TWO (2). 

PRIORITY-THREE (3). 

PRIORITY-FOUR (4). 

PRIORITY-FIVE (5). 

PRIORITY-SIX (6). 

PRIORITY-SEVEN (7). 

PRIORITY-EIGHT (8). 

PRIORITY-NINE (9). 

PRIORITY-TEN(IO). 

PRIORITY-ELEVEN (11). 

PRIORITY-TWELVE (12). 

PRIORITY-THIRTEEN (13). 

PRIORITY-FOURTEEN (14). 

PRI0RITY-FIFTEEN(15). 

6.4.24 Session-Bundle-ld AVP 

The Session-Bundle-Id (AVP code 400) is of type Unsigned32. It may be specified by the A-RACF in the AA-Answer, 
when the initial reservation is granted, in order to identify the group of sessions to which the session of the AA-Answer 
belongs. The value of the Session-Bundle-Id AVP is meaningful for the A-RACF only. It may be included by the 
A-RACF in subsequent Abort-Session-Request (ASR) messages sent to the SPDF. 

6.4.25 AF-Clnarging-ldentifier AVP 

The AF-Charging-Identifier AVP (AVP code 505) is of type OctetString, contains the AF Charging Identifier that is 
sent by the AF. This information may be used for charging correlation between AF and RACS functional entities. 

6.4.26 Service-Class AVP 

The Service-Class AVP (AVP code 459) is of type UTF8String, and it contains the service class requested by the SPDF. 
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6.4.27 Transport-Class AVP 



The Transport-Class AVP (AVP code 311) is of type Unsigned32, and it contains an integer used as an index pointing 
to a class of transport services to be applied (e.g. forwarding behaviour). 

6.4.28 Overbooking-indicator AVP 

The Overbooking indicator AVP (AVP code 460) is of type Enumerated, indicates that the SPDF should require 
processing the resource request in overbooking mode. The following values are specified: 

• NO-OVERBOOKING (0) 

Means that no overbooking mode is required 

• OVERBOOKING (1) 

Means that overbooking is mode required 
If this AVP is not included, it is assumed that no overbooking is required. 

6.4.29 Authorization-Package-Id AVP 

The Authorization-Package-Id AVP (AVP code 461) is of type UTFSString, and it identifies an authorization context 
requested by the AF for the session. This information is used by the A-RACF to derive the policy to be passed to an 
RCEF through the Re reference point for the session. 

6.4.30 Media-Authorization-Context-Id AVP 

The Media-Authorization-Context-Id AVP (AVP code 462) is of type UTFSString, and it identifies the authorization 
context requested by the AF for a media component. This information is used by the A-RACF to derive the policy to be 
passed to an RCEF through the Re reference point for a media component. 

6.4.31 Logical-Access-ID AVP 

The Logical-Access-ID AVP (AVP code 302 13019) is of type OctetString. It is defined in [4]. 
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Annex A (informative): 

Resource reservation flow states maintained by A-RACF 

Table A.1 : Flow state transitions 



State 


Event 


Action 


Next State 


Idle 


Received Reservation 
Request 


Verify availability of resource. Wait for the 
Resource Availability event. 


Idle 


Idle 


Received 

Reservation&Commit 

Request 


Verify availability of resource and perform 
Resource Reservation Commit. Wait for the 
Successful Enforcement event. 


Idle 


Idle 


Resource Availability 


Send AAA with the Result-Code AVP set to 
DIAMETER_SUCCESS. Initialize 
Authorization-Lifetime and Auth-Grace-Period 
timers (in case of soft-state). 


Reserved 


Idle 


Resource not available 


Send AAA with the Experimental-Result-Code AVP 
set to INSUFFICIENT RESOURCES. 


Idle 


Idle 


Successful Resource 

Reservation 

Enforcement 


Send AAA with the Result-Code AVP set to 
DIAMETER_SUCCESS. Initialize 
Authorization-Lifetime and Auth-Grace-Period 
timers (in case of soft-state). 


Committed 


Idle 


Unsuccessful 
Resource Reservation 
Enforcement 


Send AAA with the Experimental-Result-Code AVP 
set to COMMIT_FAILURE. 


Idle 


Reserved 


Received Commit 
Request 


Enforce Resource Reservation in network elements 
(i.e. RCEF). 


Reserved 


Reserved 


Successful Resource 

Reservation 

Enforcement 


Send AAA with the Result-Code AVP set to 
DIAMETER_SUCCESS. 


Committed 


Reserved 


Unsuccessful 
Resource Reservation 
Enforcement 


Send AAA with the Experimental-Result-Code AVP 
to COMMIT_FAILURE. 


Idle 


Reserved 


Received STR 


Send STA, cleanup. 


Idle 


Reserved 


Expiration of 

Authorization-Lifetime 

timer 


Send an unsolicited RAR with the Specific-Action 

AVP set to 

INDICATION OF RESERVATION EXPIRATION. 


Reserved 


Reserved 


Expiration of 

Auth-Grace-Period 

timer 


Cleanup. 


Idle 


Reserved 


Received Resource 
Reservation Refresh 


Send AAA with the with the Result-Code AVP set 
to DIAMETER_SUCCESS. Re-initialize 
Authorization-Lifetime and Auth-Grace-Period 
timers. 


Reserved 


Reserved 


Received Modification 
Request 


Perform Resource Reservation Modification. 


Reserved 


Reserved 


Successful Resource 

Reservation 

IVIodification 


Send AAA with the Result-Code AVP set to 
DIAMETER_SUCCESS. Re-initialize 
Authorization-Lifetime and Auth-Grace-Period 
timers (in case of soft-state). 


Reserved 


Reserved 


Unsuccessful 
Resource Reservation 
IVIodification 


Send AAA with the Experimental-Result-Code AVP 
set to MODIFICATION_FAILURE. 


Reserved 


Committed 


Received Modification 
Request 


Perform Resource Reservation Modification. 


Committed 


Committed 


Successful Resource 

Reservation 

Modification 


Send AAA with the Result-Code AVP set to 
DIAMETER_SUCCESS. Re-initialize 
Authorization-Lifetime and Auth-Grace-Period 
timers (in case of soft-state). 


Committed 


Committed 


Unsuccessful 
Resource Reservation 
Modification 


Send AAA with the Experimental-Result-Code AVP 
set to MODIFICATION_FAILURE. 


Committed 
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State 


Event 


Action 


Next State 


Committed 


Expiration of 

Authorization-Lifetime 

timer 


Send an unsolicited RAR with the Specific-Action 

AVP set to 

INDICATION OF RESERVATION EXPIRATION. 


Committed 


Committed 


Received Resource 
Reservation Refresli 


Send AAA with the Result-Code AVP set to 
DIAMETER_SUCCESS. Re-initialize 
Authorization-Lifetime and Auth-Grace-Period 
timers (in case of soft-state). 


Committed 


Committed 


Expiration of 

Auth-Grace-Period 

timer 


Cleanup. 


Idle 


Committed 


Received STR 


Release resources, cleanup. 


Idle 


All 


Critical Event Detected 


Send ASR with appropriate Abort-Cause AVP, 
cleanup. 


Idle 


All 

J 


Non Critical Event 
Detected 


Send RAR with appropriate Specific-Action AVP. 


Unchanged 



£75/ 



33 



ETSI TS 183 026 V3.1.1 (2010-03) 



Annex B (informative): 
Change history 



Date 


WG Doc. 


CR 


Rev 


CAT 


Title / Comment 


Current 
Version 


New 
Version 


29-06-07 


14bTD303r1 


001 




B 


Overbooking requirement 


1.4.0 


2.0.0 


07-09-07 


14tTD566 


002 




A 


Wrong Flow-Status during session modification 


2.0.0 


2.1.0 


29-10-07 


15bTD199r1 


003 




F 


Rq interface AAR command Correction 


2.1.0 


2.2.0 


07-03-08 


1 6bTD207r1 


005 




B 


Adding authorization pacl<age ID to Rq 


2.2.0 


2.3.0 


30-05-08 


1 7bTD232r1 


007 




D 


Rq Reference model update 


2.3.0 


2.3.1 


18-06-08 










Update of figure format by rapporteur 


2.3.1 


2.3.2 


19-06-08 










Addition of Change History annex by ETSI 
Secretariat 


2.3.2 


2.3.3 


02-07-08 


1 8WTD298r3 


008 


1 


D 


Rq overbooking procedures 


2.3.3 


2.3.4 


02-07-08 


18WTD303r1 


009 




D 


New AVP code allocation 


2.3.3 


2.3.4 


02-07-08 










Correction to Change history table 


2.3.4 


2.3.5 












Publication 


2.3.5 


2.4.1 


06-11-09 


22bTD080r1 


001 




F 


Update of the Reservation priority AVP for Rq 


2.4.1 


3.0.0 


06-11-09 


22bTD066r1 


002 




F 


Wl 3210 AF-Application-ld alignment with 29.209 


2.4.1 


3.0.0 


06-11-09 


22bTD079r3 


003 




B 


WI3210 - Rq - IVIulticast notification support 


2.4.1 


3.0.0 


15-12-09 


23WTD093r1 


004 




B 


IVIultiple Improvements 


3.0.0 


3.0.1 












Publication 


3.0.1 


3.1.1 
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Document history 


VI. 1.1 


June 2006 


Publication as ES 283 026 


Vl.4.1 


September 2007 


Publication as ES 283 026 


Vl.6.0 


April 2008 


Publication as ES 283 026 


V2.4.1 


November 2008 


Publication as ES 283 026 


V3.1.1 


March 2010 


Publication 
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